更改触发器或操作键

更改场景

在需要重写触发器/操作/搜索的自定义代码，或用新版本 v2 替换旧版本 v1 的情况下。

对用户的影响

在新版本中删除触发器/操作/搜索是一种破坏性变更，这将阻止用户迁移到新版本。如果更新现有触发器/操作/搜索的自定义代码，则虽可实现用户迁移，但如果输出发生变化，会导致用户的 Zap 出现故障。

触发器、操作和搜索通过其键（例如 new_contact 或 create_post）进行标识。如果从应用程序定义中移除该键，或对其进行更改（仅适用于 CLI 应用程序），在尝试迁移时会显示相关消息。

最佳实践

• 如果您已重命名键（仅适用于 CLI 应用程序），则需先将其切换回之前的键，以继续迁移用户。
• 如果需要删除触发器/操作/搜索，请改为将其可见性设置为隐藏。在UI中使用可见性选项下拉菜单，或在CLI中使用 hidden 键。

已迁移的 Zap 中使用隐藏触发器/操作/搜索的部分，现在会在 Zap 编辑器中显示为已弃用，但只要端点保持有效，它们将继续正常运行。

一旦用户在编辑 Zap 时选择了不同的触发器/操作/搜索，他们将无法再访问隐藏的那个。新用户不会看到任何已设置为 hidden 的触发器/操作/搜索作为可选项。

• 如果需要添加新触发器/操作/搜索来替换隐藏的那个，请创建一个副本，并为其分配新键（例如在末尾添加 _v2），如果用户功能相同，则保持名称和描述一致。

• 这样，现有 Zap 在迁移后会继续使用之前的（现已隐藏的）定义正常运行，而新 Zap 仅能选择新定义。

• 如果隐藏触发器/操作/搜索的端点即将停用并开始返回错误，对用户的影响如下：

一旦 API 停用，使用受影响触发器/操作/搜索的激活 Zap（已开启）在运行时会产生错误。根据用户的电子邮件通知设置，这些 Zap 的所有者会收到相关错误通知。

如果这些 Zap 超过错误比率并且用户未覆盖相关设置，这些 Zap 将被自动关闭。

• 如果您希望在端点停用时为隐藏的触发器/操作/搜索在 Zapier 中添加自定义错误，可以考虑以下方法：

创建一个集成的新版本，在受影响触发器/操作/搜索的 perform 方法中立即抛出 z.errors.Error 异常。详细了解，适用于UI维护的应用程序或CLI。

在接近停用日期时，推广并迁移用户到此新版本。

这种方法的优势包括：

• 抛出显式异常将确保受影响 Zap 尽快达到错误比率（并被关闭）。
• 您可以在异常中添加用户友好的消息，用户将在 Zap 运行历史记录和电子邮件错误通知中看到，例如：此功能已弃用且不再可用。
• 以下是自定义错误消息在 Zap 历史记录中显示于操作的示例：